Copilot PR Review

Iteration 13 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Totals: 0 knowledge-backed · 1 agent findings.

Orchestrator pre-filter (2 file(s) excluded)

• layer-disabled (knowledge) : 2 file(s)

_{Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives.}

Agentic PR Review - Round 1

Recommendation: Request Changes

[AI-PR-REVIEW] version=1 system=github pr=8940 round=1 by=alexei-dobriansky at=2026-07-08 lastSha=d4c04d17cb88f721e51a807e442fb5e2eab5153f suggestions=S1,S2,S3

@neeleshsinghal please review if the suggestions are valid

@alexei-dobriansky yes suggestions seems to be valid. I ll fix and commit the changes.

@alexei-dobriansky
Changes has been done based on the suggestions.

Agentic PR Review - Round 3

Recommendation: Request Changes

[AI-PR-REVIEW] version=1 system=github pr=8940 round=3 by=alexei-dobriansky at=2026-07-09 lastSha=17417f1cfd8bb2997665f13c2d3c214643df8800 suggestions=S1:addressed,S2:notaddressed,S3:addressed parentRound=2

@neeleshsinghal will approve after the buddy build goes through

Agentic PR Review - Round 4

Recommendation: Request Changes

[AI-PR-REVIEW] version=1 system=github pr=8940 round=4 by=alexei-dobriansky at=2026-07-09 lastSha=10476ea7a6aeeb5204c7048c725525604178f046 suggestions=S1:addressed,S2:notaddressed,S3:addressed parentRound=3

Agentic PR Review - Round 5

Recommendation: Accept

[AI-PR-REVIEW] version=1 system=github pr=8940 round=5 by=alexei-dobriansky at=2026-07-09T23:08:49Z lastSha=226d13a04efeedcf27934a13b6947f73d5b52564 suggestions=S1:addressed,S2:addressed,S3:addressed parentRound=4

$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 8}}$

This fix isolates the GUI path from a leaked wider 'Date Filter' by unconditionally resetting Rec.SetRange("Date Filter", 0D, WorkDate()) inside OnAfterGetCurrRecordFunc (called on every GUI record change), but the OData/API client path (OnAfterGetCurrRecordFuncOData, invoked when ClientTypeManagement.GetCurrentClientType() is ODataV4 or Api) never resets the filter on subsequent record navigations — only the one-time conditional reset in OnOpenPage's non-GUI branch applies, and only if the filter was still empty at that moment.

The page directly binds field("Balance Due (LCY)"; Rec."Balance Due (LCY)") to this FlowField, so an OData/API caller that inherits or sets a wider 'Date Filter' upper bound before/while iterating Customer Card entities (the same class of bug this PR's test 'OverdueBalanceIsolatedFromLeakedWideDateFilterOnCustomer' targets for the GUI) can still receive an inflated 'Balance Due (LCY)' value through the API surface. If material impact would otherwise be major, note it here: this should be promoted to a knowledge-backed rule and the fix extended to OnAfterGetCurrRecordFuncOData (or centralized in a single place both paths call) before being treated as fully resolved. This applies identically across all ten localized layers (APAC, BE, ES, FR, GB, IT, NA, NL, NO, RU) since the same pattern was replicated verbatim.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 11}}$

The PR fixes a real bug where a wide 'Date Filter' leaked onto the Customer record (e.g.

from a document/journal caller) corrupted 'Balance Due (LCY)' (CalcFormula uses upperlimit("Date Filter")) and the background-task 'Balance Due' cue. The fix only resets Rec.SetRange("Date Filter", 0D, WorkDate()) inside OnAfterGetCurrRecordFunc, which runs solely on the GuiAllowed()=true branch of trigger OnAfterGetCurrRecord. The other two branches of that same trigger are untouched: OnAfterGetCurrRecordFuncOData() (ClientType OData/Api) calls CustomerMgt.CalculateStatistic(Rec, ...) directly against Rec without resetting the filter, and the plain non-GUI/non-OData branch calls StartBackgroundCalculations() directly, which captures Rec.GetView() as-is. Both branches can still be reached with the same leaked wide Date Filter (e.g. a web-service/OData client or a background job that opens the page with a pre-set filter) and will reproduce the exact miscalculation this PR sets out to fix, just outside the interactive path the new test exercises. Note: if this can be confirmed as commonly reachable in production (e.g. OData API consumers of the Customer/Customer Card entity), the real severity is closer to major/blocker than the capped 'minor' shown here — recommend adding the same Date Filter reset (or a shared helper) to OnAfterGetCurrRecordFuncOData and to the background-task branch, and extending the new test to cover both. This same gap is replicated identically across all 11 changed layer files (APAC, BE, ES, FR, GB, IT, NA, NL, NO, RU, W1), since each applies the same partial fix.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

@neeleshsinghal will approve after the buddy build goes through

@alexei-dobriansky Sure.

@alexei-dobriansky Can you please approve this PR?

$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 13}}$

The fix for the leaked wide "Date Filter" (Bug 640988) is applied asymmetrically between the interactive and non-interactive code paths of the same page.

In the GUI path, OnAfterGetCurrRecordFunc now unconditionally executes Rec.SetRange("Date Filter", 0D, WorkDate()) on every OnAfterGetCurrRecord, so any inherited wide filter is normalized before StartBackgroundCalculations captures Rec.GetView(). But when GuiAllowed() is false and the client type is not OData/Api, OnAfterGetCurrRecord instead calls StartBackgroundCalculations() directly (bypassing OnAfterGetCurrRecordFunc), and the only remaining reset is the pre-existing conditional one in OnOpenPage's else-branch ("if Rec.GetFilter('Date Filter') = '' then SetRange(...)"), which only runs once at page open and only when no filter is already present. A caller that opens this page headlessly (e.g. an automated/background client-type invocation) with an inherited wide Date Filter, or that changes the filter between records during that session, will still compute OverdueBalance/Balance Due (LCY) against the leaked wider window - the exact defect this PR sets out to fix - because the per-record normalization added in OnAfterGetCurrRecordFunc never runs on that path. Recommend applying the same unconditional Rec.SetRange("Date Filter", 0D, WorkDate()) (or an equivalent normalization) ahead of the StartBackgroundCalculations() call in OnAfterGetCurrRecord's non-GUI, non-OData branch, so the fix covers headless invocations of this page as well as interactive ones. This same asymmetry is replicated identically in all ten localized copies of this page (APAC, BE, ES, FR, GB, IT, NA, NL, NO, RU CustomerCard.Page.al), not only the W1 layer.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}